RuntimeQueue

ActiveBatch provides a special built-in Queue named RuntimeQueue. The RuntimeQueue provides a Job author with the ability to set a Job's Queue at run-time by using a special ActiveBatch variable named #queue. The RuntimeQueue cannot be deleted, copied or moved. It can be renamed, although its label cannot be changed.

 

Below you will find a RuntimeQueue example.

 

Suppose Job1, running on Server10, performs some processing, but then needs to tell Job2 (the next Job in the stream) to execute on Queue Server20. To accomplish this, Job1 can set a variable that would tell Job2 what Queue to execute on. That is the purpose of the RunTimeQueue and the special #queue variable.

 

In continuing with the above example:

 

Job1:

 

Configure a Jobs Library Job Step as follows:

 

  • Category: ActiveBatch

  • Step Name: Set Variable

  • Variable Name: #queue

  • Variable Value: The fullpath to the Queue that points to Server20. For example: /Shared Objects/Server20_Queue

 

Job2:

 

  • Assign the RuntimeQueue to Job2's Submission Queue property.

  • All Queues that #queue can possibly resolve to must be added to Job2's Associations property sheet. If you don't do this and the Job is dispatched to a Queue not in the Associations list, it will fail with an "Access denied" Exit Code Description when it runs.

 

 

Next, add a completion trigger on Job1, to trigger Job2 upon a successful completion. When Job1 triggers Job2, Job1 will pass the #queue variable (what the Set Variable Job Step does) to Job2, where the value is the fullpath of the Queue where Job2 will run. In any Instances view, look for the Queue that Job2 ran on.  It should be the Queue that the variable #queue was set to in Job1, whose value was then passed to Job2.

 

Note: If you are running a Script or Process Job type (not a Jobs Library Job), you can use the built-in Abatset command-line utility to pass the #queue variable to a downstream Job. The Set Variable Job Step and Abatset essentially do the same thing. although Abatset does have some additional functionality. See Command Line Utilities for information about AbatSet.

 

The above example is just one way to use the RuntimeQueue. You may have other scenarios for which it will come in handy.

 

Finally, ASCI used to recommend that you use the RuntimeQueue for Reference Jobs - if you wanted the Reference Job to run on a system that differed from the Queue set on the Job that the Reference Job was pointing to.  In older versions of ActiveBatch, Reference Jobs always inherited the Queue from the Job it was referencing (pointing to). To work around this, ASCI suggested you use the RuntimeQueue functionality if you wanted the Reference Job to run on a different system - and not the inherited Queue. However, in more recent versions of ActiveBatch, you can now set the Submission Queue for the Reference Job. ASCI still supports using the RuntimeQueue as a way to accomplish this task, but setting the Queue on the Reference Job is much easier, and therefore now recommended over using the RuntimeQueue, in this scenario.

 

 

Note: The VariableQueue has been deprecated and replaced with the RuntimeQueue. You will only see VariableQueue built into the product if you used it before it was replaced by the RuntimeQueue. Newer versions of ActiveBatch do not include the VariableQueue.